ci: run the test suite and documentation build on every push and pull request - #7
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Make GitHub run pyEDW's tests automatically on every push and every pull request so nothing lands untested. Add a GitHub Actions workflow at .github/workflows/tests.yml that installs the library exactly the way the repository's own published instructions describe - using the 'test' extra via 'pip install -e ".[test]"' rather than installing pytest by hand - runs the suite with pytest, and does so across the FULL range of Python versions the repository claims to support. That claim is read from pyproject.toml (requires-python >=3.8 plus classifiers through 3.14) and the README ('Requires Python 3.8+'), so the matrix is deliberately 3.8 through 3.14 rather than a convenient subset; do not suggest trimming it. A second job builds the manual with the 'docs' extra so a broken documentation build is caught too. The workflow was deliberately kept boring: only actions/checkout and actions/setup-python, a plain version matrix, no dependency caching, no third-party actions. fail-fast is off on purpose so one bad version does not hide the others. The venv steps in the published recipe are intentionally omitted because setup-python already provides an isolated interpreter. This was verified before opening the PR: the branch was pushed and run 32224265656 came back green - all seven Python versions passed 11 tests each (3.8 resolves numba 0.58.1, 3.14 resolves current numba) and the docs job built successfully, which confirms the claimed 3.8-3.14 range is真 and means the published install instructions needed no correction. Scope is deliberately limited to adding the workflow file and nothing else. PR title must be one plain sentence.
What Changed
.github/workflows/tests.yml, which triggers on every push and pull request and installs the package withpip install -e ".[test]"(the sametestextra the published instructions use) before runningpytest.pyproject.tomland the README - Python 3.8 through 3.14 - withfail-fast: falseso one failing version does not mask the rest, using onlyactions/checkoutandactions/setup-pythonwith no dependency caching or third-party actions.docsjob that installs thedocsextra and runsmake htmlindocs/, plus a top-levelpermissions: contents: readblock so the workflow token is read-only.Run 32224265656 on this branch came back green: all seven Python versions passed 11 tests each and the docs job built successfully, so the claimed 3.8-3.14 range holds and the install instructions needed no correction.
Risk Assessment
✅ Low: The branch adds a single self-contained CI workflow file with no production-code impact, satisfies every source-verifiable acceptance criterion, and the review fix was a minimal least-privilege
contents: readaddition that leaves all other behavior untouched.Testing
I validated the workflow the way an end user experiences it - through GitHub Actions itself - rather than only reading the YAML. The branch's run 32224265656 is green with all seven matrix jobs (3.8 through 3.14) plus the docs job, and I captured the Actions run page as a screenshot along with the Python 3.8 job log showing numba 0.58.1 resolving and 11 tests passing, which substantiates the deliberately full 3.8-3.14 range. I then reproduced both jobs' exact recipes locally at the target commit -
pip install -e ".[test]"+pytest(11 passed) andpip install -e ".[docs]"+make html(build succeeded) - confirming the published extras recipe is sufficient with no hand-installed pytest, and parsed the target-commit YAML to confirm the triggers, permissions block, fail-fast off, and the checkout/setup-python-only step list. Two limits worth noting: the green run is for a6077aa, so the review commit's inertpermissions: contents: readaddition has not itself been run on GitHub yet, and only the push trigger has fired in a real run - the pull_request half is declared but will first execute when the PR opens, both of which the pipeline's own push and CI phases cover. Everything passed; the temporary venv and generateddocs/_build,.pytest_cache, egg-info, and__pycache__artifacts were removed and the worktree is clean.Evidence: CI job results for run 32224265656
run: 32224265656 status: completed conclusion: success branch: fm/ci-pyedw event: push jobs: docs success test (3.8) success test (3.9) success test (3.10) success test (3.11) success test (3.12) success test (3.13) success test (3.14) successEvidence: Python 3.8 CI job - oldest supported version resolves and passes
Evidence: Local reproduction of the test job recipe
$ pip install -e ".[test]" Successfully installed ... numba-0.67.0 numpy-2.5.2 pyEDW-0.1.0 pytest-9.1.1 scipy-1.18.0 ... $ pytest platform darwin -- Python 3.14.5, pytest-9.1.1, pluggy-1.6.0 configfile: pyproject.toml collected 11 items tests/test_metrics.py ..... [ 45%] tests/test_model.py ...... [100%] = 11 passed in 10.64s ==Evidence: Local reproduction of the docs job recipe
$ pip install -e ".[docs]" Successfully installed ... sphinx-9.1.0 sphinx-copybutton-0.5.2 sphinx-rtd-theme-3.1.0 sphinxcontrib-bibtex-2.7.0 ... $ cd docs && make html writing output... [100%] theory generating indices... genindex py-modindex done build succeeded. The HTML pages are in _build/html.Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 3 issues found → auto-fixed ✅
.github/workflows/tests.yml:38- The docs job runsmake htmlwithoutSPHINXOPTS: -W, so Sphinx warnings do not fail the build. Broken cross-references, missing toctree entries, unresolvedfootcitekeys against docs/references.bib, and autodoc import warnings all exit 0, so the job only catches hard build errors rather than a genuinely broken manual. Addingenv: SPHINXOPTS: -Wto the step would close the gap, but it changes how strict CI is, so it is the author's call..github/workflows/tests.yml:3-on: push:andpull_request:are both unfiltered, so a branch pushed in this repo and then opened as a PR runs all 8 jobs twice per push, and tag pushes also trigger full runs. This matches the stated intent ("every push and every pull request") and is free on a public repo; noting the tradeoff only. Narrowing topush: branches: [main]pluspull_request:, or adding aconcurrencygroup to cancel superseded runs, would halve the work if it ever becomes a concern..github/workflows/tests.yml:1- No top-levelpermissions:block, so the GITHUB_TOKEN handed to actions/checkout inherits the repository default, which may be read/write. Neither job needs write access. Addingpermissions:\n contents: readat the workflow level is standard least-privilege hardening and does not conflict with the "only checkout and setup-python, no third-party actions" constraint.🔧 Fix: Add top-level contents:read permissions to tests workflow
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
gh-axi run list --workflow tests.ymlandgh-axi run view 32224265656- confirmed conclusion success for jobs test (3.8) through test (3.14) and docs on branch fm/ci-pyedwgh-axi run view 32224265656 --job 95980673565 --log- inspected the Python 3.8 job log; resolves numba 0.58.1 / numpy 1.24.4 on CPython 3.8.18 and reports11 passed in 9.29sCaptured a full-page screenshot of https://github.com/EternalTime/pyEDW/actions/runs/32224265656 viachrome-devtools-axi screenshot --full-pageshowing all 8 jobs greenLocal reproduction of the test job recipe in a throwaway venv:pip install -e ".[test]"thenpytest-> 11 passed (Python 3.14.5)Local reproduction of the docs job recipe:pip install -e ".[docs]"thenmake htmlindocs/->build succeededParsed.github/workflows/tests.ymlat target commit 6201c68 with PyYAML to confirm push/pull_request triggers,permissions: contents: read,fail-fast: false, the 3.8-3.14 matrix, and only actions/checkout@v4 + actions/setup-python@v5 with no cachinggit status --porcelain --ignoredafter cleanup - worktree clean, no build artifacts left behinddocs/getting_started.rst:78- Judgment call, no edit made: the repository now runs tests and the docs build automatically on every push and PR, but nothing documents that contract to contributors. There is no CONTRIBUTING.md to own contribution mechanics, and the placement policy says not to create a new documentation surface merely to close a perceived gap, so I did not add one. The 'Running the tests' section of docs/getting_started.rst (the authority on install/test mechanics per README) would be the natural owner for a one-line note that CI runs the same commands across Python 3.8-3.14, if the author wants it documented. Nothing existing was made stale, so this is optional follow-up rather than a defect.✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.